home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc802.txt < prev    next >
Text File  |  1994-08-01  |  60KB  |  2,673 lines

  1.                       
  2.                           
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.          RFC 802: The ARPANET 1822L Host Access Protocol
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.                          Andrew G. Malis
  24.                      Netmail: malis@bbn-unix
  25.  
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32.  
  33.                   Bolt Beranek and Newman Inc.
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.                           November 1981
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60. RFC 802                                           Andrew G. Malis
  61.  
  62.  
  63.  
  64.                         Table of Contents
  65.  
  66.  
  67.  
  68.  
  69. 1   INTRODUCTION.......................................... 1
  70. 2   THE ARPANET 1822L HOST ACCESS PROTOCOL................ 4
  71. 2.1   Addresses and Names................................. 6
  72. 2.2   Name Authorization and Effectiveness................ 8
  73. 2.3   Uncontrolled Messages.............................. 14
  74. 2.4   The Short-Blocking Feature......................... 15
  75. 2.4.1   Host Blocking.................................... 16
  76. 2.4.2   Reasons for Host Blockage........................ 19
  77. 2.5   Establishing Host-IMP Communications............... 22
  78. 3   1822L LEADER FORMATS................................. 25
  79. 3.1   Host-to-IMP 1822L Leader Format.................... 26
  80. 3.2   IMP-to-Host 1822L Leader Format.................... 34
  81. 4   REFERENCES........................................... 42
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.                               - i -
  114.  
  115.  
  116.  
  117.  
  118. RFC 802                                           Andrew G. Malis
  119.  
  120.  
  121.  
  122.                              FIGURES
  123.  
  124.  
  125.  
  126.  
  127. 1822 Address Format....................................... 6
  128. 1822L Name Format......................................... 7
  129. 1822L Address Format...................................... 7
  130. Communications between different host types.............. 13
  131. Host-to-IMP 1822L Leader Format.......................... 27
  132. NDM Message Format....................................... 30
  133. IMP-to-Host 1822L Leader Format.......................... 35
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.                              - ii -
  172.  
  173.  
  174.  
  175.  
  176. RFC 802                                           Andrew G. Malis
  177.  
  178.  
  179.  
  180. 1  INTRODUCTION
  181.  
  182.  
  183. This document proposes two major changes to the  current  ARPANET
  184.  
  185. host  access  protocol.  The first change will allow hosts to use
  186.  
  187. logical addressing (i.e., host addresses that are independent  of
  188.  
  189. their  physical location on the ARPANET) to communicate with each
  190.  
  191. other, and the second will allow a host to shorten the amount  of
  192.  
  193. time  that  it  may  be  blocked  by  its IMP after it presents a
  194.  
  195. message to the network (currently,  the  IMP  can  block  further
  196.  
  197. input from a host for up to 15 seconds).
  198.  
  199.  
  200. The new host access protocol is known as the ARPANET  1822L  (for
  201.  
  202. Logical)  Host  Access Protocol, and it represents an addition to
  203.  
  204. the current ARPANET 1822 Host Access Protocol, which is described
  205.  
  206. in  sections  3.3  and  3.4 of BBN Report 1822 [1].  Although the
  207.  
  208. 1822L protocol uses different  Host-IMP  leaders  than  the  1822
  209.  
  210. protocol,  hosts  using  either  protocol can readily communicate
  211.  
  212. with each other (the IMPs handle the translation automatically).
  213.  
  214.  
  215. The new option for shortening the host blocking timeout is called
  216.  
  217. the short-blocking feature, and it replaces the non-blocking host
  218.  
  219. interface described in section 3.7 of Report 1822.  This  feature
  220.  
  221. will  be  available  to  all  hosts  on  C/30  IMPs (see the next
  222.  
  223. paragraph), regardless of whether they  use  the  1822  or  1822L
  224.  
  225. protocol.
  226.  
  227.  
  228.  
  229.                               - 1 -
  230.  
  231.  
  232.  
  233.  
  234. RFC 802                                           Andrew G. Malis
  235.  
  236.  
  237.  
  238. There is one major restriction  to  the  new  capabilities  being
  239.  
  240. described.   Both  the  1822L  protocol  and  the  short-blocking
  241.  
  242. feature will be implemented on C/30 IMPs only, and will therefore
  243.  
  244. only be useable by hosts connected to C/30 IMPs, as the Honeywell
  245.  
  246. and Pluribus IMPs do not have sufficient memory to hold  the  new
  247.  
  248. programs  and  tables.   This restriction also means that logical
  249.  
  250. addressing cannot be used to address a host on  a  non-C/30  IMP.
  251.  
  252. However, the ARPANET will shortly be completely converted to C/30
  253.  
  254. IMPs, and at that time this  restriction  will  no  longer  be  a
  255.  
  256. problem.
  257.  
  258.  
  259. I will try to keep my terminology consistent with  that  used  in
  260.  
  261. Report  1822, and will define new terms when they are first used.
  262.  
  263. Of course, familiarity with Report 1822 (section 3 in particular)
  264.  
  265. is assumed.
  266.  
  267.  
  268. This document  makes  many  references  to  Report  1822.   As  a
  269.  
  270. convenient  abbreviation,  I  will  use  "see 1822(x)" instead of
  271.  
  272. "please refer to Report 1822, section x, for further details".
  273.  
  274.  
  275. This document is a proposal, not a description of an  implemented
  276.  
  277. system.   Thus,  described  features  are subject to change based
  278.  
  279. upon responses to this  document  and  restrictions  that  become
  280.  
  281. evident  during  implementation.   However,  any such changes are
  282.  
  283. expected to be minor.  A new RFC will be made available once  the
  284.  
  285.  
  286.  
  287.                               - 2 -
  288.  
  289.  
  290.  
  291.  
  292. RFC 802                                           Andrew G. Malis
  293.  
  294.  
  295.  
  296. implementation  is  complete containing the actual as-implemented
  297.  
  298. description.
  299.  
  300.  
  301. Finally, I would like to thank Dr. Eric C. Rosen, who wrote  most
  302.  
  303. of section 2.4, and James G. Herman, Dr. Paul J. Santos Jr., John
  304.  
  305. F.  Haverty, and Robert M. Hinden, all of  BBN,  who  contributed
  306.  
  307. many of the ideas found herein.
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.                               - 3 -
  346.  
  347.  
  348.  
  349.  
  350. RFC 802                                           Andrew G. Malis
  351.  
  352.  
  353.  
  354. 2  THE ARPANET 1822L HOST ACCESS PROTOCOL
  355.  
  356.  
  357. The ARPANET  1822L  Host  Access  Protocol,  which  replaces  the
  358.  
  359. ARPANET  1822  Host  Access  Protocol  described  in Report 1822,
  360.  
  361. sections 3.3 and 3.4, allows a host to use logical addressing  to
  362.  
  363. communicate  with other hosts on the ARPANET.  Basically, logical
  364.  
  365. addressing allows hosts to refer to each  other  using  an  1822L
  366.  
  367. name  (see section 2.1) which is independent of a host's physical
  368.  
  369. location in the network.  IEN 183 (also published as  BBN  Report
  370.  
  371. 4473)  [2]  gives  the  use  of  logical  addressing considerable
  372.  
  373. justification.  Among the advantages it cites are:
  374.  
  375.  
  376. o The ability to refer to each host on  the  network  by  a  name
  377.  
  378.   independent of its location on the network.
  379.  
  380.  
  381. o Allowing different hosts to share  the  same  host  port  on  a
  382.  
  383.   time-division basis.
  384.  
  385.  
  386. o Allowing a host to use multi-homing (where a single  host  uses
  387.  
  388.   more than one port to communicate with the network).
  389.  
  390.  
  391. o And allowing several hosts that provide  the  same  service  to
  392.  
  393.   share the same name.
  394.  
  395.  
  396. The main differences between the 1822 and 1822L protocols are the
  397.  
  398. format of the leaders that are used to introduce messages between
  399.  
  400.  
  401.  
  402.  
  403.                               - 4 -
  404.  
  405.  
  406.  
  407.  
  408. RFC 802                                           Andrew G. Malis
  409.  
  410.  
  411.  
  412. a host and an IMP, and the specification in those leaders of  the
  413.  
  414. source  and/or  destination  host(s).   Hosts  have the choice of
  415.  
  416. using the 1822 or the 1822L protocol.  When a host comes up on an
  417.  
  418. IMP,  it declares itself to be an 1822 host or an 1822L host host
  419.  
  420. by the type of NOP message (see section 3.1) it uses.   Once  up,
  421.  
  422. hosts  can  switch  from  one protocol to the other by issuing an
  423.  
  424. appropriate NOP.  Hosts that do not use the 1822L  protocol  will
  425.  
  426. still  be  addressable by and can communicate with hosts that do,
  427.  
  428. and vice-versa.
  429.  
  430.  
  431. Another difference between the two protocols  is  that  the  1822
  432.  
  433. leaders are symmetric, while the 1822L leaders are not.  The term
  434.  
  435. symmetric means that in the 1822 protocol, the exact same  leader
  436.  
  437. format  is used for messages in both directions between the hosts
  438.  
  439. and IMPs.  For example, a leader sent from a host  over  a  cable
  440.  
  441. that  was  looped  back onto itself (via a looping plug or faulty
  442.  
  443. hardware) would arrive back at the host and appear to be a  legal
  444.  
  445. message  from  a  real host (the destination host of the original
  446.  
  447. message).  In contrast, the 1822L headers are not symmetric,  and
  448.  
  449. a  host  can  detect  if  the  connection to its IMP is looped by
  450.  
  451. receiving a message with the wrong leader  format.   This  allows
  452.  
  453. the host to take appropriate action upon detection of the loop.
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.                               - 5 -
  462.  
  463.  
  464.  
  465.  
  466. RFC 802                                           Andrew G. Malis
  467.  
  468.  
  469.  
  470. 2.1  Addresses and Names
  471.  
  472.  
  473. The 1822 protocol defines one form of host specification, and the
  474.  
  475. 1822L  protocol  defines  two additional ways to identify network
  476.  
  477. hosts.  These three forms are 1822 addresses,  1822L  names,  and
  478.  
  479. 1822L addresses.
  480.  
  481.  
  482. 1822 addresses are  the  24-bit  host  addresses  found  in  1822
  483.  
  484. leaders.  They have the following format:
  485.  
  486.  
  487.  
  488.        1              8 9                              24
  489.       +----------------+---------------------------------+
  490.       |                |                                 |
  491.       |  Host number   |           IMP number            |
  492.       |                |                                 |
  493.       +----------------+---------------------------------+
  494.  
  495.                  Figure 1. 1822 Address Format
  496.  
  497.  
  498.  
  499. These fields are quite large, and the ARPANET will never use more
  500.  
  501. than  a  fraction of the available address space.  1822 addresses
  502.  
  503. are used in 1822 leaders only.
  504.  
  505.  
  506. 1822L names are 16-bit unsigned numbers that serve as  a  logical
  507.  
  508. identifier  for  one  or  more  hosts.   1822L  names have a much
  509.  
  510. simpler format:
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.                               - 6 -
  520.  
  521.  
  522.  
  523.  
  524. RFC 802                                           Andrew G. Malis
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.                 1                             16
  532.                +--------------------------------+
  533.                |                                |
  534.                |           1822L name           |
  535.                |                                |
  536.                +--------------------------------+
  537.  
  538.                   Figure 2. 1822L Name Format
  539.  
  540.  
  541.  
  542. The 1822L names are just 16-bit  unsigned  numbers,  except  that
  543.  
  544. bits  1  and  2 are not both zeros (see below).  This allows over
  545.  
  546. 49,000 hosts to be specified.
  547.  
  548.  
  549. 1822 addresses cannot be used in 1822L leaders, but there may  be
  550.  
  551. a  requirement for an 1822L host to be able to address a specific
  552.  
  553. physical host port or IMP fake host.  1822L  addresses  are  used
  554.  
  555. for  this  function.   1822L addresses form a subset of the 1822L
  556.  
  557. name space, and have both bits 1 and 2 off.
  558.  
  559.  
  560.  
  561.                1   2  3          8 9             16
  562.              +---+---+------------+----------------+
  563.              |   |   |            |                |
  564.              | 0 | 0 |   host #   |   IMP number   |
  565.              |   |   |            |                |
  566.              +---+---+------------+----------------+
  567.  
  568.                  Figure 3. 1822L Address Format
  569.  
  570.  
  571.  
  572.  
  573.  
  574.  
  575.  
  576.  
  577.                               - 7 -
  578.  
  579.  
  580.  
  581.  
  582. RFC 802                                           Andrew G. Malis
  583.  
  584.  
  585.  
  586. This format gives 1822L hosts the  ability  to  directly  address
  587.  
  588. hosts  0-59  at  IMPs 1-255 (IMP 0 does not exist).  Host numbers
  589.  
  590. 60-63 are reserved for addressing the four  fake  hosts  at  each
  591.  
  592. IMP.
  593.  
  594.  
  595.  
  596.  
  597. 2.2  Name Authorization and Effectiveness
  598.  
  599.  
  600. Every host on a C/30 IMP, regardless of whether it is  using  the
  601.  
  602. 1822 or 1822L protocol to access the network, will be assigned at
  603.  
  604. least one 1822L name (logical address).  Other 1822L  hosts  will
  605.  
  606. use  this name to address the host, wherever it may be physically
  607.  
  608. located.  Because of the implementation constraints mentioned  in
  609.  
  610. the introduction, hosts on non-C/30 IMPs cannot be assigned 1822L
  611.  
  612. names.  To circumvent this restriction, however, 1822L hosts  can
  613.  
  614. use  1822L addresses to access all other hosts on the network, no
  615.  
  616. matter where they reside.
  617.  
  618.  
  619. At this point, several questions  arise:   How  are  these  names
  620.  
  621. assigned,  how  do  they  become  known  to  the  IMPs  (so  that
  622.  
  623. translations to physical addresses can be made), and how  do  the
  624.  
  625. IMPs know which host is currently using a shared port?  To answer
  626.  
  627. each question in order:
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.                               - 8 -
  636.  
  637.  
  638.  
  639.  
  640. RFC 802                                           Andrew G. Malis
  641.  
  642.  
  643.  
  644. Names are assigned by a central network administrator.  When each
  645.  
  646. name  is  created, it is assigned to a host (or a group of hosts)
  647.  
  648. at one or more specific host ports.  The host(s) are  allowed  to
  649.  
  650. reside at those specific host ports, and nowhere else.  If a host
  651.  
  652. moves, it will keep the same name, but the administrator  has  to
  653.  
  654. update  the  central  database  to  reflect  the  new  host port.
  655.  
  656. Changes to this database are  distributed  to  the  IMPs  by  the
  657.  
  658. Network  Operations  Center  (NOC) at BBN.  For a while, the host
  659.  
  660. may be allowed to reside at either of (or both) the new  and  old
  661.  
  662. ports.   Once  the  correspondence between a name and one or more
  663.  
  664. hosts ports where it may be used has been made  official  by  the
  665.  
  666. administrator,   that  name  is  said  to  be  authorized.  1822L
  667.  
  668. addresses, which actually  refer  to  physical  host  ports,  are
  669.  
  670. always authorized in this sense.
  671.  
  672.  
  673. Once a host has been assigned one or more names, it  has  to  let
  674.  
  675. the  IMPs  know  where it is and what name(s) it is using.  There
  676.  
  677. are two cases to consider, one for 1822L hosts  and  another  for
  678.  
  679. 1822  hosts.   The following discussion only pertains to hosts on
  680.  
  681. C/30 IMPs.
  682.  
  683.  
  684. When an IMP sees an 1822L host come up on a host  port,  the  IMP
  685.  
  686. has  no way of knowing which host has just come up (several hosts
  687.  
  688. may share the same port, or one host may prefer to  be  known  by
  689.  
  690.  
  691.  
  692.  
  693.                               - 9 -
  694.  
  695.  
  696.  
  697.  
  698. RFC 802                                           Andrew G. Malis
  699.  
  700.  
  701.  
  702. different  names  at different times).  This requires the host to
  703.  
  704. let the IMP know what is happening before it  can  actually  send
  705.  
  706. and  receive messages.  This function is performed by a new host-
  707.  
  708. to-IMP message, the Name Declaration Message (NDM),  which  lists
  709.  
  710. the  names  that  the  host  would  like to be known by.  The IMP
  711.  
  712. checks its tables to see if each of the names is authorized,  and
  713.  
  714. sends an NDM Reply to the host saying which names in the list can
  715.  
  716. be used for sending and receiving messages (i.e., which names are
  717.  
  718. effective). A host can also use an NDM message to change its list
  719.  
  720. of effective addresses (it can add to and delete from  the  list)
  721.  
  722. at  any  time.  The only constraint on the host is that any names
  723.  
  724. it  wishes  to  use  can  become  effective  only  if  they   are
  725.  
  726. authorized.
  727.  
  728.  
  729. In the second case, if a host comes up on a C/30  IMP  using  the
  730.  
  731. 1822 protocol, the IMP automatically makes the first name the IMP
  732.  
  733. finds in its tables for that host become effective.   Thus,  even
  734.  
  735. though  the host is using the 1822 protocol, it can still receive
  736.  
  737. messages from 1822L hosts via its 1822L name.  Of course, it  can
  738.  
  739. also receive messages from an 1822L host via its 1822L address as
  740.  
  741. well.   (Remember,  the  distinction  between  1822L  names   and
  742.  
  743. addresses  is that the addresses correspond to physical locations
  744.  
  745. on  the  network,  while   the   names   are   strictly   logical
  746.  
  747. identifiers).   The  IMPs translate between the different leaders
  748.  
  749.  
  750.  
  751.                              - 10 -
  752.  
  753.  
  754.  
  755.  
  756. RFC 802                                           Andrew G. Malis
  757.  
  758.  
  759.  
  760. and send the proper leader in each case (more on this below).
  761.  
  762.  
  763. The third question above has by now already been answered.   When
  764.  
  765. an  1822L  host comes up, it uses the NDM message to tell the IMP
  766.  
  767. which host it is (which names it is known by).  Even if this is a
  768.  
  769. shared port, the IMP knows which host is currently connected.
  770.  
  771.  
  772. Whenever a host goes down, its names  automatically  become  non-
  773.  
  774. effective.   When it comes back up, it has to make them effective
  775.  
  776. again.
  777.  
  778.  
  779. Several hosts can share the same 1822L name.  If more than one of
  780.  
  781. these  hosts  is  up  at the same time, any messages sent to that
  782.  
  783. 1822L name will be delivered to just one  of  the  hosts  sharing
  784.  
  785. that  name,  and  a RFNM will be returned as usual.  However, the
  786.  
  787. sending host will  not  receive  any  indication  of  which  host
  788.  
  789. received  the  message,  and subsequent messages to that name are
  790.  
  791. not guaranteed to be sent to the  same  host.   Typically,  hosts
  792.  
  793. providing  exactly  the  same  service could share the same 1822L
  794.  
  795. name in this manner.
  796.  
  797.  
  798. Similarly, when a host is multi-homed, the same  1822L  name  may
  799.  
  800. refer  to  more  than  one  host  port (all connected to the same
  801.  
  802. host).  If the host is up on only one of those ports,  that  port
  803.  
  804. will  be  used for all messages addressed to it.  However, if the
  805.  
  806.  
  807.  
  808.  
  809.                              - 11 -
  810.  
  811.  
  812.  
  813.  
  814. RFC 802                                           Andrew G. Malis
  815.  
  816.  
  817.  
  818. host were up  on  more  than  one  port,  the  message  would  be
  819.  
  820. delivered  over  just  one  of  those ports, and the subnet would
  821.  
  822. choose which port to use.  This port selection could change  from
  823.  
  824. message  to  message.   If  a  host wanted to insure that certain
  825.  
  826. messages were delivered to it on specific ports,  these  messages
  827.  
  828. could  use  either  the  port's 1822L address or a specific 1822L
  829.  
  830. name that referred to that port alone.
  831.  
  832.  
  833. Some further details are required on communications between  1822
  834.  
  835. and  1822L  hosts.   Obviously, when 1822 hosts converse, or when
  836.  
  837. 1822L hosts converse, no conversions between leaders and  address
  838.  
  839. formats  are  required.   However,  this becomes more complicated
  840.  
  841. when 1822 and 1822L hosts converse with each other.
  842.  
  843.  
  844. The   following   figure   illustrates   how   these   addressing
  845.  
  846. combinations  are  handled,  showing  how  each  type of host can
  847.  
  848. access every other type of host.  There are three types of hosts:
  849.  
  850. "1822  on  C/30"  signifies  an  1822 host that is on a C/30 IMP,
  851.  
  852. "1822L" signifies an 1822L host (on a C/30  IMP),  and  "1822  on
  853.  
  854. non-C/30"  signifies  a  host  on  an  non-C/30 IMP (which cannot
  855.  
  856. support the 1822L protocol).  The table entry shows the  protocol
  857.  
  858. and  host address format(s) that the source host can use to reach
  859.  
  860. the destination host.
  861.  
  862.  
  863.  
  864.  
  865.  
  866.  
  867.                              - 12 -
  868.  
  869.  
  870.  
  871.  
  872. RFC 802                                           Andrew G. Malis
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879.                             Destination Host
  880.   Source
  881.   Host    | 1822 on C/30   | 1822L          | 1822 on non-C/30
  882.   --------+----------------+----------------+-----------------
  883.           |                |                |
  884.   1822 on | 1822           | 1822           | 1822
  885.   C/30    |                | (note 1)       |
  886.           |                |                |
  887.   --------+----------------+----------------+-----------------
  888.           |                |                |
  889.           | 1822L, using   | 1822L, using   | 1822L, using
  890.   1822L   | 1822L name or  | 1822L name or  | 1822L address
  891.           |address (note 2)| address        | only (note 2)
  892.           |                |                |
  893.   --------+----------------+----------------+-----------------
  894.           |                |                |
  895.   1822 on | 1822           | 1822           | 1822
  896.   non-C/30|                | (note 1)       |
  897.           |                |                |
  898.   --------+----------------+----------------+-----------------
  899.  
  900.   Note 1: The message is presented  to  the  destination  host
  901.           with  an 1822L leader containing the 1822L addresses
  902.           of the source  and  destination  hosts.   If  either
  903.           address  cannot be encoded as an 1822L address, then
  904.           the message is not delivered and and  error  message
  905.           is sent to the source host.
  906.  
  907.   Note 2: The message is presented  to  the  destination  host
  908.           with  an  1822 leader containing the 1822 address of
  909.           the source host.
  910.  
  911.  
  912.      Figure 4. Communications between different host types
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.                              - 13 -
  926.  
  927.  
  928.  
  929.  
  930. RFC 802                                           Andrew G. Malis
  931.  
  932.  
  933.  
  934. 2.3  Uncontrolled Messages
  935.  
  936.  
  937. Uncontrolled messages (see 1822(3.6)) present  a  unique  problem
  938.  
  939. for  the  1822L  protocol.  Uncontrolled messages use none of the
  940.  
  941. normal ordering and error-control mechanisms in the IMP,  and  do
  942.  
  943. not  use  the  normal  subnetwork  connection  facilities.   As a
  944.  
  945. result, uncontrolled messages need to carry all of their overhead
  946.  
  947. with  them, including source and destination addresses.  If 1822L
  948.  
  949. addresses  are  used  when  sending  an   uncontrolled   message,
  950.  
  951. additional information is now required by the subnetwork when the
  952.  
  953. message is transferred to the destination IMP.  This  means  that
  954.  
  955. less  host-to-host  data  can be contained in the message than is
  956.  
  957. possible between 1822 hosts.
  958.  
  959.  
  960. Uncontrolled messages  that  are  sent  between  1822  hosts  may
  961.  
  962. contain  not  more  than 991 bits of data.  Uncontrolled messages
  963.  
  964. that are sent to and/or from 1822L hosts are limited to  32  bits
  965.  
  966. less,  or  not  more  than  959  bits.  Messages that exceed this
  967.  
  968. length will result in an error indication to the  host,  and  the
  969.  
  970. message  will  not  be sent.  This error indication represents an
  971.  
  972. enhancement to the previous level of service provided by the IMP,
  973.  
  974. which  would  simply  discard an overly long uncontrolled message
  975.  
  976. without notification.
  977.  
  978.  
  979.  
  980.  
  981.  
  982.  
  983.                              - 14 -
  984.  
  985.  
  986.  
  987.  
  988. RFC 802                                           Andrew G. Malis
  989.  
  990.  
  991.  
  992. Other enhancements that are  provided  for  uncontrolled  message
  993.  
  994. service  are  a  notification  to the host of any message-related
  995.  
  996. errors that are detected by the host's IMP when it  receives  the
  997.  
  998. message.   A  host  will  be  notified if an uncontrolled message
  999.  
  1000. contains an error in the 1822L name specification,  such  as  the
  1001.  
  1002. name  not being authorized or effective, or if the remote host is
  1003.  
  1004. unreachable (which is  indicated  by  none  of  its  names  being
  1005.  
  1006. effective),  or  if  network  congestion  control  throttled  the
  1007.  
  1008. message before it left the source IMP.   The  host  will  not  be
  1009.  
  1010. notified  if  the  uncontrolled  message was lost for some reason
  1011.  
  1012. once it was transmitted by the source IMP.
  1013.  
  1014.  
  1015.  
  1016.  
  1017. 2.4  The Short-Blocking Feature
  1018.  
  1019.  
  1020. The short-blocking feature of the 1822  and  1822L  protocols  is
  1021.  
  1022. designed  to  allow a host to present messages to the IMP without
  1023.  
  1024. causing the IMP to not accept further messages from the host  for
  1025.  
  1026. long amounts of time (up to 15 seconds).  It is a replacement for
  1027.  
  1028. the non-blocking host interface described in 1822(3.7), and  that
  1029.  
  1030. description should be ignored.
  1031.  
  1032.  
  1033.  
  1034.  
  1035.  
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.                              - 15 -
  1042.  
  1043.  
  1044.  
  1045.  
  1046. RFC 802                                           Andrew G. Malis
  1047.  
  1048.  
  1049.  
  1050. 2.4.1  Host Blocking
  1051.  
  1052.  
  1053. Most commonly, when a source host submits a message  to  an  IMP,
  1054.  
  1055. the  IMP  immediately  processes that message and sends it on its
  1056.  
  1057. way to its destination host.  Sometimes, however, the IMP is  not
  1058.  
  1059. able  to  process  the message immediately.  Processing a message
  1060.  
  1061. requires a significant number of resources, and when the  network
  1062.  
  1063. is heavily loaded, there can sometimes be a long delay before the
  1064.  
  1065. necessary resources become available.  In  such  cases,  the  IMP
  1066.  
  1067. must  make  a decision as to what to do while it is attempting to
  1068.  
  1069. gather the resources.
  1070.  
  1071.  
  1072. One possibility is for the IMP to stop  accepting  messages  from
  1073.  
  1074. the  source  host  until  it has gathered the resources needed to
  1075.  
  1076. process the message just submitted.  This strategy  is  known  as
  1077.  
  1078. blocking  the  host,  and is basically the strategy that has been
  1079.  
  1080. used in the ARPANET up to the present.  When  a  host  submits  a
  1081.  
  1082. message  to  an  IMP, all further transmissions from that host to
  1083.  
  1084. that IMP are blocked until the message can be processed.
  1085.  
  1086.  
  1087. It is important to note, however, that not all  messages  require
  1088.  
  1089. the  same  set  of resources in order to be processed by the IMP.
  1090.  
  1091. The particular set of resources needed will depend on the message
  1092.  
  1093. type, the message length, and the destination host of the message
  1094.  
  1095. (see below).  Therefore, although it might take a  long  time  to
  1096.  
  1097.  
  1098.  
  1099.                              - 16 -
  1100.  
  1101.  
  1102.  
  1103.  
  1104. RFC 802                                           Andrew G. Malis
  1105.  
  1106.  
  1107.  
  1108. gather  the  resources needed to process some particular message,
  1109.  
  1110. it might take only a short time to gather the resources needed to
  1111.  
  1112. process  some  other  message.   This  fact exposes a significant
  1113.  
  1114. disadvantage in the strategy of blocking the host.  A host  which
  1115.  
  1116. is  blocked may have many other messages to submit which, if only
  1117.  
  1118. they could be submitted, could be processed immediately.   It  is
  1119.  
  1120. "unfair"  for  the IMP to refuse to accept these message until it
  1121.  
  1122. has gathered the resources for  some  other,  unrelated  message.
  1123.  
  1124. Why  should messages for which the IMP has plenty of resources be
  1125.  
  1126. delayed for an arbitrarily long amount of time just  because  the
  1127.  
  1128. IMP lacks the resources needed for some other message?
  1129.  
  1130.  
  1131. A simple way to alleviate the problem would be to place  a  limit
  1132.  
  1133. on  the  amount of time during which a host can be blocked.  This
  1134.  
  1135. amount  of  time  should  be  long  enough  so  that,   in   most
  1136.  
  1137. circumstances,  the  IMP  will  be  able  to gather the resources
  1138.  
  1139. needed to process the message within the given time period.   If,
  1140.  
  1141. however, the resources cannot be gathered in this period of time,
  1142.  
  1143. the IMP will flush the message, sending a  reply  to  the  source
  1144.  
  1145. host   indicating   that  the  message  was  not  processed,  and
  1146.  
  1147. specifying the reason that it could not be  processed.   However,
  1148.  
  1149. the  resource gathering process would continue.  The intention is
  1150.  
  1151. that the host  resubmit  the  message  in  a  short  time,  when,
  1152.  
  1153. hopefully,   the   resource   gathering   process  has  concluded
  1154.  
  1155.  
  1156.  
  1157.                              - 17 -
  1158.  
  1159.  
  1160.  
  1161.  
  1162. RFC 802                                           Andrew G. Malis
  1163.  
  1164.  
  1165.  
  1166. successfully.   In  the  meantime,  the  host  can  submit  other
  1167.  
  1168. messages,  which may be processed sooner.  This strategy does not
  1169.  
  1170. eliminate the phenomenon of host blocking, but  only  limits  the
  1171.  
  1172. time  during  which  a  host is blocked.  This shorter time limit
  1173.  
  1174. will generally fall somewhere in the range of 100 milliseconds to
  1175.  
  1176. 2  seconds,  with  its value possibly depending on the reason for
  1177.  
  1178. the blocking.
  1179.  
  1180.  
  1181. Note, however, that there  is  a  disadvantage  to  having  short
  1182.  
  1183. blocking  times.  Let us say that the IMP accepts a message if it
  1184.  
  1185. has all the resources needed to process it.  The ARPANET provides
  1186.  
  1187. a  sequential  delivery  service,  whereby messages with the same
  1188.  
  1189. priority, source host, and destination host are delivered to  the
  1190.  
  1191. destination  host in the same order as they are accepted from the
  1192.  
  1193. source host.  With short blocking times, however,  the  order  in
  1194.  
  1195. which  the  IMP accepts messages from the source host need not be
  1196.  
  1197. the same as  the  order  in  which  the  source  host  originally
  1198.  
  1199. submitted  the messages.  Since the two data streams (one in each
  1200.  
  1201. direction) between the host and the IMP are not synchronized, the
  1202.  
  1203. host  may  not  receive the reply to a rejected message before it
  1204.  
  1205. submits subsequent messages of the same  priority  for  the  same
  1206.  
  1207. destination host.  If a subsequent message is accepted, the order
  1208.  
  1209. of acceptance differs from the order of original submission,  and
  1210.  
  1211. the ARPANET will not provide the same type of sequential delivery
  1212.  
  1213.  
  1214.  
  1215.                              - 18 -
  1216.  
  1217.  
  1218.  
  1219.  
  1220. RFC 802                                           Andrew G. Malis
  1221.  
  1222.  
  1223.  
  1224. that it has in the past.
  1225.  
  1226.  
  1227. Up to now, type 0 (regular)  messages  have  only  had  sub-types
  1228.  
  1229. available  to  request the standard blocking timeout.  The short-
  1230.  
  1231. blocking feature makes available new  sub-types  that  allow  the
  1232.  
  1233. host  to  request  messages to be short-blocking, i.e. only cause
  1234.  
  1235. the host to be blocked for a short amount of time if the  message
  1236.  
  1237. cannot be immediately processed.   See section 3.1 for a complete
  1238.  
  1239. list of the available sub-types.
  1240.  
  1241.  
  1242. If sequential delivery by the subnet is a strict requirement,  as
  1243.  
  1244. would  be  the  case  for  messages  produced  by NCP, the short-
  1245.  
  1246. blocking feature cannot be used.  For messages produced  by  TCP,
  1247.  
  1248. however,  the  use  of  the short-blocking feature is allowed and
  1249.  
  1250. recommended.
  1251.  
  1252.  
  1253.  
  1254.  
  1255. 2.4.2  Reasons for Host Blockage
  1256.  
  1257.  
  1258. There are a number of reasons why a message could  cause  a  long
  1259.  
  1260. blockage  in  the  IMP,  which would result in the rejection of a
  1261.  
  1262. short-blocking message.  The IMP  signals  this  rejection  of  a
  1263.  
  1264. short-blocking message by using the Incomplete Transmission (Type
  1265.  
  1266. 9) message, using the sub-type field to  indicate  which  of  the
  1267.  
  1268. above  reasons  caused the rejection of the message.  See section
  1269.  
  1270.  
  1271.  
  1272.  
  1273.                              - 19 -
  1274.  
  1275.  
  1276.  
  1277.  
  1278. RFC 802                                           Andrew G. Malis
  1279.  
  1280.  
  1281.  
  1282. 3.2 for a summary of the Incomplete Transmission  message  and  a
  1283.  
  1284. complete  list of its sub-types.  The sub-types that apply to the
  1285.  
  1286. short-blocking feature are:
  1287.  
  1288.  
  1289. 6.  Connection setup-delay: Although the IMP  presents  a  simple
  1290.  
  1291.     message-at-a-time  interface  to  the  host,  it  provides an
  1292.  
  1293.     internal  connection-oriented  (virtual   circuit)   service,
  1294.  
  1295.     except  in  the  case  of  uncontrolled messages (see section
  1296.  
  1297.     2.3).   Two  messages  are  considered  to  be  on  the  same
  1298.  
  1299.     connection  if they have the same source host (i.e., they are
  1300.  
  1301.     submitted to the same IMP over the same host interface),  the
  1302.  
  1303.     same priority, and the same destination host name or address.
  1304.  
  1305.     The subnet maintains internal connection set-up and tear-down
  1306.  
  1307.     procedures.   Connections  are set up as needed, and are torn
  1308.  
  1309.     down  only  after  a  period  of  inactivity.   Occasionally,
  1310.  
  1311.     network  congestion or resource shortage will cause a lengthy
  1312.  
  1313.     delay in connection set-up.  During this period, no  messages
  1314.  
  1315.     for  that  connection can be accepted, but other messages can
  1316.  
  1317.     be accepted.
  1318.  
  1319.  
  1320. 7.  End-to-end flow  control:  For  every  message  that  a  host
  1321.  
  1322.     submits  to  an  IMP  (except  uncontrolled messages) the IMP
  1323.  
  1324.     eventually  returns  a  reply  to  the  host  indicating  the
  1325.  
  1326.     disposition  of  the  message.   Between  the  time  that the
  1327.  
  1328.  
  1329.  
  1330.  
  1331.                              - 20 -
  1332.  
  1333.  
  1334.  
  1335.  
  1336. RFC 802                                           Andrew G. Malis
  1337.  
  1338.  
  1339.  
  1340.     message is submitted and  the  time  the  host  receives  the
  1341.  
  1342.     reply,  the  message  is  said to be outstanding. The ARPANET
  1343.  
  1344.     allows  only  eight  outstanding  messages   on   any   given
  1345.  
  1346.     connection.   If  there  are  eight outstanding messages on a
  1347.  
  1348.     given connection, and a ninth is  submitted,  it  cannot  the
  1349.  
  1350.     accepted.  If  a message is refused because its connection is
  1351.  
  1352.     blocked due to flow control, messages  on  other  connections
  1353.  
  1354.     can still be accepted.
  1355.  
  1356.  
  1357.     End-to-end flow control is the  most  common  cause  of  host
  1358.  
  1359.     blocking in the ARPANET at present.
  1360.  
  1361.  
  1362. 8.  Destination IMP buffer space shortage: If the host submits  a
  1363.  
  1364.     message  of  more  than  1008  bits  (exclusive of the 96-bit
  1365.  
  1366.     leader), buffer space at the destination IMP must be reserved
  1367.  
  1368.     before  the  message  can  be  accepted.  Buffer space at the
  1369.  
  1370.     destination IMP is always reserved on a per-connection basis.
  1371.  
  1372.     If  the  destination  IMP  is  heavily loaded, there may be a
  1373.  
  1374.     lengthy wait for the buffer space;  this  is  another  common
  1375.  
  1376.     cause  of  blocking  in  the  present  ARPANET.  Messages are
  1377.  
  1378.     rejected  for  this  reason  based  on   their   length   and
  1379.  
  1380.     connection;  messages  of  1008 or fewer bits or messages for
  1381.  
  1382.     other connections may still be acceptable.
  1383.  
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.                              - 21 -
  1390.  
  1391.  
  1392.  
  1393.  
  1394. RFC 802                                           Andrew G. Malis
  1395.  
  1396.  
  1397.  
  1398. 9.  Congestion control: A message may be refused for  reasons  of
  1399.  
  1400.     congestion  control if the path via the intermediate IMPs and
  1401.  
  1402.     lines to the destination IMP is too heavily loaded to  handle
  1403.  
  1404.     additional  traffic.   Messages  to other destinations may be
  1405.  
  1406.     acceptable, however.
  1407.  
  1408.  
  1409. 10.  Local resource shortage: Sometimes the source IMP itself  is
  1410.  
  1411.     short  of buffer space, table entries, or some other resource
  1412.  
  1413.     that it needs to accept a message.  Unlike the other  reasons
  1414.  
  1415.     for message rejection, this resource shortage will affect all
  1416.  
  1417.     messages equally,  except  for  uncontrolled  messages.   The
  1418.  
  1419.     message's size or connection is not relevant.
  1420.  
  1421.  
  1422. The short-blocking feature is available  to  all  hosts  on  C/30
  1423.  
  1424. IMPs,  whether they are using the 1822 or 1822L protocol, through
  1425.  
  1426. the use of Type 0, sub-type 1 and 2 messages.  A host using these
  1427.  
  1428. sub-types  should  be  prepared  to  correctly  handle Incomplete
  1429.  
  1430. Transmission messages from the IMP.
  1431.  
  1432.  
  1433.  
  1434.  
  1435. 2.5  Establishing Host-IMP Communications
  1436.  
  1437.  
  1438. When a host comes up on an IMP, or after there has been  a  break
  1439.  
  1440. in   the  communications  between  the  host  and  its  IMP  (see
  1441.  
  1442. 1822(3.2)), the orderly flow of messages between the host and the
  1443.  
  1444.  
  1445.  
  1446.  
  1447.                              - 22 -
  1448.  
  1449.  
  1450.  
  1451.  
  1452. RFC 802                                           Andrew G. Malis
  1453.  
  1454.  
  1455.  
  1456. IMP  needs  to  be properly (re)established.  This allows the IMP
  1457.  
  1458. and host to recover from most any failure  in  the  other  or  in
  1459.  
  1460. their communications path, including a break in mid-message.
  1461.  
  1462.  
  1463. The first messages that a host should send to its IMP  are  three
  1464.  
  1465. NOP  messages.   Three  messages  are  required to insure that at
  1466.  
  1467. least one message will be properly read by the IMP (the first NOP
  1468.  
  1469. could be concatenated to a previous message if communications had
  1470.  
  1471. been broken in mid-stream, and the third provides redundancy  for
  1472.  
  1473. the   second).    These   NOPs   serve  several  functions:  they
  1474.  
  1475. synchronize the IMP with the host, they tell  the  IMP  how  much
  1476.  
  1477. padding  the  host  requires  between  the message leader and its
  1478.  
  1479. body, and they also tell the IMP whether the host will  be  using
  1480.  
  1481. 1822 or 1822L leaders.
  1482.  
  1483.  
  1484. Similarly, the IMP will send three  NOPs  to  the  host  when  it
  1485.  
  1486. detects  that  the host has come up.  Actually, the IMP will send
  1487.  
  1488. six NOPs, alternating three 1822  NOPs  with  three  1822L  NOPs.
  1489.  
  1490. Thus, the host will see three NOPs no matter which protocol it is
  1491.  
  1492. using.   The  NOPs  will  be  followed  by  two  Interface  Reset
  1493.  
  1494. messages,  one of each style.  If the IMP receives a NOP from the
  1495.  
  1496. host while the above sequence is occurring,  the  IMP  will  only
  1497.  
  1498. send  the  remainder  of  the NOPs and the Interface Reset in the
  1499.  
  1500. proper style.  The 1822 NOPs will contain the 1822 address of the
  1501.  
  1502.  
  1503.  
  1504.  
  1505.                              - 23 -
  1506.  
  1507.  
  1508.  
  1509.  
  1510. RFC 802                                           Andrew G. Malis
  1511.  
  1512.  
  1513.  
  1514. host interface, and the 1822L NOPs will contain the corresponding
  1515.  
  1516. 1822L address.
  1517.  
  1518.  
  1519. Once the IMP  and  the  host  have  sent  each  other  the  above
  1520.  
  1521. messages, regular communications can commence.  See 1822(3.2) for
  1522.  
  1523. further details concerning the ready line,  host  tardiness,  and
  1524.  
  1525. other issues.
  1526.  
  1527.  
  1528.  
  1529.  
  1530.  
  1531.  
  1532.  
  1533.  
  1534.  
  1535.  
  1536.  
  1537.  
  1538.  
  1539.  
  1540.  
  1541.  
  1542.  
  1543.  
  1544.  
  1545.  
  1546.  
  1547.  
  1548.  
  1549.  
  1550.  
  1551.  
  1552.  
  1553.  
  1554.  
  1555.  
  1556.  
  1557.  
  1558.  
  1559.  
  1560.  
  1561.  
  1562.  
  1563.                              - 24 -
  1564.  
  1565.  
  1566.  
  1567.  
  1568. RFC 802                                           Andrew G. Malis
  1569.  
  1570.  
  1571.  
  1572. 3  1822L LEADER FORMATS
  1573.  
  1574.  
  1575. The following sections describe the formats of the  leaders  that
  1576.  
  1577. precede  messages  between  an 1822L host and its IMP.  They were
  1578.  
  1579. designed to be as compatible with the 1822 leaders  as  possible.
  1580.  
  1581. The  second,  fifth,  and  sixth  words  are identical in the two
  1582.  
  1583. leaders, and all  of  the  existing  functionality  of  the  1822
  1584.  
  1585. leaders has been retained.  The first difference one will note is
  1586.  
  1587. in the first word.  The 1822 New Format Flag is now also used  to
  1588.  
  1589. identify  the  two  types of 1822L leaders, and the Handling Type
  1590.  
  1591. has been moved to the second byte.  The third  and  fourth  words
  1592.  
  1593. contain the Source and Destination 1822L Name, respectively.
  1594.  
  1595.  
  1596.  
  1597.  
  1598.  
  1599.  
  1600.  
  1601.  
  1602.  
  1603.  
  1604.  
  1605.  
  1606.  
  1607.  
  1608.  
  1609.  
  1610.  
  1611.  
  1612.  
  1613.  
  1614.  
  1615.  
  1616.  
  1617.  
  1618.  
  1619.  
  1620.  
  1621.                              - 25 -
  1622.  
  1623.  
  1624.  
  1625.  
  1626. RFC 802                                           Andrew G. Malis
  1627.  
  1628.  
  1629.  
  1630. 3.1  Host-to-IMP 1822L Leader Format
  1631.  
  1632.  
  1633.  
  1634.  
  1635.  
  1636.                1      4 5      8 9             16
  1637.               +--------+--------+----------------+
  1638.               |        |  1822L |                |
  1639.               | Unused |  H2I   | Handling Type  |
  1640.               |        |  Flag  |                |
  1641.               +--------+--------+----------------+
  1642.                17    20 21 22 24 25            32
  1643.               +--------+-+------+----------------+
  1644.               |        |T|Leader|                |
  1645.               | Unused |R|Flags |  Message Type  |
  1646.               |        |C|      |                |
  1647.               +--------+-+------+----------------+
  1648.                33                              48
  1649.               +----------------------------------+
  1650.               |                                  |
  1651.               |           Source Host            |
  1652.               |                                  |
  1653.               +----------------------------------+
  1654.                49                              64
  1655.               +----------------------------------+
  1656.               |                                  |
  1657.               |         Destination Host         |
  1658.               |                                  |
  1659.               +----------------------------------+
  1660.                65                     76 77    80
  1661.               +-------------------------+--------+
  1662.               |                         |        |
  1663.               |       Message ID        |Sub-type|
  1664.               |                         |        |
  1665.               +-------------------------+--------+
  1666.                81                              96
  1667.               +----------------------------------+
  1668.               |                                  |
  1669.               |              Unused              |
  1670.               |                                  |
  1671.               +----------------------------------+
  1672.  
  1673.            Figure 5. Host-to-IMP 1822L Leader Format
  1674.  
  1675.  
  1676.  
  1677.  
  1678.  
  1679.                              - 26 -
  1680.  
  1681.  
  1682.  
  1683.  
  1684. RFC 802                                           Andrew G. Malis
  1685.  
  1686.  
  1687.  
  1688. Bits 1-4: Unused, must be set to zero.
  1689.  
  1690.  
  1691. Bits 5-8: 1822L Host-to-IMP Flag:
  1692.  
  1693.      This field is set to decimal 13 (1101 in binary).
  1694.  
  1695.  
  1696. Bits 9-16: Handling Type:
  1697.  
  1698.      This  field  is  bit-coded  to  indicate  the   transmission
  1699.  
  1700.      characteristics  of  the connection desired by the host. See
  1701.  
  1702.      1822(3.3).
  1703.  
  1704.      Bit 9: Priority Bit:
  1705.  
  1706.           Messages with this bit on will be treated  as  priority
  1707.  
  1708.           messages.
  1709.  
  1710.      Bits 10-16: Unused, must be zero.
  1711.  
  1712.  
  1713. Bits 17-20: Unused, must be zero.
  1714.  
  1715.  
  1716. Bit 21: Trace Bit:
  1717.  
  1718.      If equal to one, this message is designated for  tracing  as
  1719.  
  1720.      it proceeds through the network.  See 1822(5.5).
  1721.  
  1722.  
  1723. Bits 22-24: Leader Flags:
  1724.  
  1725.      Bit 22: A flag available for use by  the  destination  host.
  1726.  
  1727.           See 1822(3.3) for a description of its use by the IMP's
  1728.  
  1729.           TTY fake host.
  1730.  
  1731.      Bits 23-24: Reserved for future use, must be zero.
  1732.  
  1733.  
  1734.  
  1735.  
  1736.  
  1737.                              - 27 -
  1738.  
  1739.  
  1740.  
  1741.  
  1742. RFC 802                                           Andrew G. Malis
  1743.  
  1744.  
  1745.  
  1746. Bits 25-32: Message Type:
  1747.  
  1748.      Type 0: Regular Message  -  All  host-to-host  communication
  1749.  
  1750.           occurs  via  regular  messages, which have several sub-
  1751.  
  1752.           types, found in bits 77-80.  These sub-types are:
  1753.  
  1754.           0: Standard - The IMP uses its full message  and  error
  1755.  
  1756.                control facilities, and host blocking (see section
  1757.  
  1758.                2.4) may occur.
  1759.  
  1760.           1: Standard, short-blocking - See section 2.4.
  1761.  
  1762.           2: Uncontrolled, short-blocking - See section 2.4.
  1763.  
  1764.           3: Uncontrolled - The  IMP  will  perform  no  message-
  1765.  
  1766.                control  functions  for  this type of message, and
  1767.  
  1768.                network flow and congestion control  (see  section
  1769.  
  1770.                2.4)  may  cause  loss  of  the message.  Also see
  1771.  
  1772.                1822(3.6) and section 2.3.
  1773.  
  1774.           4-15: Unassigned.
  1775.  
  1776.      Type 1: Error Without Message ID - See 1822(3.3).
  1777.  
  1778.      Type 2: Host Going Down - see 1822(3.3).
  1779.  
  1780.      Type 3: Name Declaration Message (NDM)  -  This  message  is
  1781.  
  1782.           used by the host to declare which of its 1822L names is
  1783.  
  1784.           or is not effective (see section 2.2), or to  make  all
  1785.  
  1786.           of  its  names non-effective.  The first 16 bits of the
  1787.  
  1788.           data portion of the NDM message, following  the  leader
  1789.  
  1790.           and  any  padding,  contains  the  number of 1822L name
  1791.  
  1792.  
  1793.  
  1794.  
  1795.                              - 28 -
  1796.  
  1797.  
  1798.  
  1799.  
  1800. RFC 802                                           Andrew G. Malis
  1801.  
  1802.  
  1803.  
  1804.           entries contained in the message.  This is followed  by
  1805.  
  1806.           the 1822L name entries, each 32 bits long, of which the
  1807.  
  1808.           first 16 bits is a 1822L name and the  second  16  bits
  1809.  
  1810.           contains  either  of  the  integers  zero or one.  Zero
  1811.  
  1812.           indicates that the name should not  be  effective,  and
  1813.  
  1814.           one  indicates  that the name should be effective.  The
  1815.  
  1816.           IMP will reply with a NDM Reply  message  (see  section
  1817.  
  1818.           3.2)  indicating  which  of the names are now effective
  1819.  
  1820.           and which are not.  Pictorially, a NDM message has  the
  1821.  
  1822.           following   format  (including  the  leader,  which  is
  1823.  
  1824.           printed in hexadecimal):
  1825.  
  1826.  
  1827.  
  1828.  
  1829.  
  1830.  
  1831.  
  1832.  
  1833.  
  1834.  
  1835.  
  1836.  
  1837.  
  1838.  
  1839.  
  1840.  
  1841.  
  1842.  
  1843.  
  1844.  
  1845.  
  1846.  
  1847.  
  1848.  
  1849.  
  1850.  
  1851.  
  1852.  
  1853.                              - 29 -
  1854.  
  1855.  
  1856.  
  1857.  
  1858. RFC 802                                           Andrew G. Malis
  1859.  
  1860.  
  1861.  
  1862.  
  1863.  
  1864.  
  1865.             1             16 17            32 33            48
  1866.            +----------------+----------------+----------------+
  1867.            |                |                |                |
  1868.            |      0D00      |      0003      |      0000      |
  1869.            |                |                |                |
  1870.            +----------------+----------------+----------------+
  1871.             49            64 65            80 81            96
  1872.            +----------------+----------------+----------------+
  1873.            |                |                |                |
  1874.            |      0000      |      0000      |      0000      |
  1875.            |                |                |                |
  1876.            +----------------+----------------+----------------+
  1877.             97           112 113          128 129          144
  1878.            +----------------+----------------+----------------+
  1879.            |                |                |                |
  1880.            |  # of entries  |  1822L name #1 |     0 or 1     |
  1881.            |                |                |                |
  1882.            +----------------+----------------+----------------+
  1883.            145           160 161          176
  1884.            +----------------+----------------+
  1885.            |                |                |
  1886.            |  1822L name #2 |     0 or 1     |       etc.
  1887.            |                |                |
  1888.            +----------------+----------------+
  1889.  
  1890.                   Figure 6. NDM Message Format
  1891.  
  1892.  
  1893.  
  1894.           An  NDM  with  zero  entries  will  cause  all  current
  1895.  
  1896.           effective names for the host to become non-effective.
  1897.  
  1898.      Type 4: NOP - This allows the IMP to  know  which  style  of
  1899.  
  1900.           leader  the  host wishes to use.  A 1822L NOP signifies
  1901.  
  1902.           that the host wishes to use 1822L leaders, and an  1822
  1903.  
  1904.           NOP signifies that the host wishes to use 1822 leaders.
  1905.  
  1906.           All of the other remarks concerning the NOP message  in
  1907.  
  1908.  
  1909.  
  1910.  
  1911.                              - 30 -
  1912.  
  1913.  
  1914.  
  1915.  
  1916. RFC 802                                           Andrew G. Malis
  1917.  
  1918.  
  1919.  
  1920.           1822(3.3)  still  hold.   The  host should always issue
  1921.  
  1922.           NOPs in groups of three to insure proper  reception  by
  1923.  
  1924.           the IMP.  Also see section 2.5 for a further discussion
  1925.  
  1926.           on the use of the NOP message.
  1927.  
  1928.      Type 8: Error with Message ID - see 1822(3.3).
  1929.  
  1930.      Types 5-7,9-255: Unassigned.
  1931.  
  1932.  
  1933. Bits 33-48: Source Host:
  1934.  
  1935.      This field contains one of the  source  host's  1822L  names
  1936.  
  1937.      (or,  alternatively,  the 1822L address of the host port the
  1938.  
  1939.      message  is  being  sent   over).    This   field   is   not
  1940.  
  1941.      automatically filled in by the IMP, as in the 1822 protocol,
  1942.  
  1943.      because the host may be known by several names and may  wish
  1944.  
  1945.      to use a particular name as the source of this message.  All
  1946.  
  1947.      messages from the same host need not use the  same  name  in
  1948.  
  1949.      this  field.   Each  source  name, when used, is checked for
  1950.  
  1951.      authorization, effectiveness, and actually belonging to this
  1952.  
  1953.      host.  Messages using names that do not satisfy all of these
  1954.  
  1955.      requirements will not be delivered, and will instead  result
  1956.  
  1957.      in  an  error  message being sent back into the source host.
  1958.  
  1959.      If the host places its 1822L  Address  in  this  field,  the
  1960.  
  1961.      address is checked to insure that it actually represents the
  1962.  
  1963.      host port where the message originated.  If the  message  is
  1964.  
  1965.      destined for an 1822 host on a non-C/30 IMP, this field MUST
  1966.  
  1967.  
  1968.  
  1969.                              - 31 -
  1970.  
  1971.  
  1972.  
  1973.  
  1974. RFC 802                                           Andrew G. Malis
  1975.  
  1976.  
  1977.  
  1978.      contain the source host's 1822L address  (see  Figure  4  in
  1979.  
  1980.      section 2.2).
  1981.  
  1982.  
  1983. Bits 49-64: Destination Host:
  1984.  
  1985.      This field  contains  the  1822L  name  or  address  of  the
  1986.  
  1987.      destination  host.   If it contains a name, the name will be
  1988.  
  1989.      checked for effectiveness, with an error message returned to
  1990.  
  1991.      the  source  host  if  the  name  is  not effective.  If the
  1992.  
  1993.      message is destined for an 1822 host on a non-C/30 IMP, this
  1994.  
  1995.      field MUST contain the destination host's 1822L address (see
  1996.  
  1997.      Figure 4 in section 2.2).
  1998.  
  1999.  
  2000. Bits 65-76: Message ID:
  2001.  
  2002.      This is a host-specified identification used in all  type  0
  2003.  
  2004.      and  type  8  messages, and is also used in type 2 messages.
  2005.  
  2006.      When used in type 0 messages, bits 65-72 are also  known  as
  2007.  
  2008.      the  Link  Field,  and  should  contain  values specified in
  2009.  
  2010.      Assigned  Numbers  [3]  appropriate  for  the   host-to-host
  2011.  
  2012.      protocol being used.
  2013.  
  2014.  
  2015. Bits 77-80: Sub-type:
  2016.  
  2017.      This field is used as a modifier by message types 0,  2,  4,
  2018.  
  2019.      and 8.
  2020.  
  2021.  
  2022.  
  2023.  
  2024.  
  2025.  
  2026.  
  2027.                              - 32 -
  2028.  
  2029.  
  2030.  
  2031.  
  2032. RFC 802                                           Andrew G. Malis
  2033.  
  2034.  
  2035.  
  2036. Bits 81-96: Unused, must be zero.
  2037.  
  2038.  
  2039.  
  2040.  
  2041.  
  2042.  
  2043.  
  2044.  
  2045.  
  2046.  
  2047.  
  2048.  
  2049.  
  2050.  
  2051.  
  2052.  
  2053.  
  2054.  
  2055.  
  2056.  
  2057.  
  2058.  
  2059.  
  2060.  
  2061.  
  2062.  
  2063.  
  2064.  
  2065.  
  2066.  
  2067.  
  2068.  
  2069.  
  2070.  
  2071.  
  2072.  
  2073.  
  2074.  
  2075.  
  2076.  
  2077.  
  2078.  
  2079.  
  2080.  
  2081.  
  2082.  
  2083.  
  2084.  
  2085.                              - 33 -
  2086.  
  2087.  
  2088.  
  2089.  
  2090. RFC 802                                           Andrew G. Malis
  2091.  
  2092.  
  2093.  
  2094. 3.2  IMP-to-Host 1822L Leader Format
  2095.  
  2096.  
  2097.  
  2098.  
  2099.  
  2100.                1      4 5      8 9             16
  2101.               +--------+--------+----------------+
  2102.               |        |  1822L |                |
  2103.               | Unused |  I2H   | Handling Type  |
  2104.               |        |  Flag  |                |
  2105.               +--------+--------+----------------+
  2106.                17    20 21 22 24 25            32
  2107.               +--------+-+------+----------------+
  2108.               |        |T|Leader|                |
  2109.               | Unused |R|Flags |  Message Type  |
  2110.               |        |C|      |                |
  2111.               +--------+-+------+----------------+
  2112.                33                              48
  2113.               +----------------------------------+
  2114.               |                                  |
  2115.               |           Source Host            |
  2116.               |                                  |
  2117.               +----------------------------------+
  2118.                49                              64
  2119.               +----------------------------------+
  2120.               |                                  |
  2121.               |         Destination Host         |
  2122.               |                                  |
  2123.               +----------------------------------+
  2124.                65                     76 77    80
  2125.               +-------------------------+--------+
  2126.               |                         |        |
  2127.               |       Message ID        |Sub-type|
  2128.               |                         |        |
  2129.               +-------------------------+--------+
  2130.                81                              96
  2131.               +----------------------------------+
  2132.               |                                  |
  2133.               |          Message Length          |
  2134.               |                                  |
  2135.               +----------------------------------+
  2136.  
  2137.            Figure 7. IMP-to-Host 1822L Leader Format
  2138.  
  2139.  
  2140.  
  2141.  
  2142.  
  2143.                              - 34 -
  2144.  
  2145.  
  2146.  
  2147.  
  2148. RFC 802                                           Andrew G. Malis
  2149.  
  2150.  
  2151.  
  2152. Bits 1-4: Unused and set to zero.
  2153.  
  2154.  
  2155. Bits 5-8: 1822L IMP-to-Host Flag:
  2156.  
  2157.      This field is set to decimal 14 (1110 in binary).
  2158.  
  2159.  
  2160. Bits 9-16: Handling Type:
  2161.  
  2162.      This has the value assigned by the source host (see  section
  2163.  
  2164.      3.1).   This  field is only used in message types 0, 5-9, 11
  2165.  
  2166.      and 15.
  2167.  
  2168.  
  2169. Bits 17-20: Unused and set to zero.
  2170.  
  2171.  
  2172. Bit 21: Trace Bit:
  2173.  
  2174.      If equal to one, the source host designated this message for
  2175.  
  2176.      tracing as it proceeds through the network.  See 1822(5.5).
  2177.  
  2178.  
  2179. Bits 22-24: Leader Flags:
  2180.  
  2181.      Bit 22: Available as a destination host flag.
  2182.  
  2183.      Bits 23-24: Reserved for future use, set to zero.
  2184.  
  2185.  
  2186. Bits 25-32: Message Type:
  2187.  
  2188.      Type 0: Regular Message  -  All  host-to-host  communication
  2189.  
  2190.           occurs  via  regular  messages, which have several sub-
  2191.  
  2192.           types.  The sub-type field (bits 77-80) is the same  as
  2193.  
  2194.           sent in the host-to-IMP leader (see section 3.1).
  2195.  
  2196.      Type 1: Error in Leader - See 1822(3.4).
  2197.  
  2198.  
  2199.  
  2200.  
  2201.                              - 35 -
  2202.  
  2203.  
  2204.  
  2205.  
  2206. RFC 802                                           Andrew G. Malis
  2207.  
  2208.  
  2209.  
  2210.      Type 2: IMP Going Down - See 1822(3.4).
  2211.  
  2212.      Type 3: NDM Reply - This is a reply to the  NDM  host-to-IMP
  2213.  
  2214.           message  (see  section  3.1).   It  will  have the same
  2215.  
  2216.           number of entries as the  NDM  message  that  is  being
  2217.  
  2218.           replying  to,  and  each  listed  1822L  name  will  be
  2219.  
  2220.           accompanied by a zero or a one.  A zero signifies  that
  2221.  
  2222.           the  name  is  not  effective, and a one means that the
  2223.  
  2224.           name is now effective.
  2225.  
  2226.      Type 4: NOP - The host should discard this message.   It  is
  2227.  
  2228.           used    during    initialization    of   the   IMP/host
  2229.  
  2230.           communication.  The Destination Host field will contain
  2231.  
  2232.           the  1822L  Address of the host port over which the NOP
  2233.  
  2234.           is being sent.  All other fields are unused.
  2235.  
  2236.      Type 5: Ready for Next Message (RFNM) - See 1822(3.4).
  2237.  
  2238.      Type 6: Dead Host Status - See 1822(3.4).
  2239.  
  2240.      Type 7: Destination Host or IMP Dead  (or  unknown)  -  This
  2241.  
  2242.           message  is  sent  in  response  to  a  message  for  a
  2243.  
  2244.           destination which the IMP cannot reach.  The message to
  2245.  
  2246.           the "dead" destination is discarded.  See 1822(3.4) for
  2247.  
  2248.           a complete list of the applicable sub-types.   If  this
  2249.  
  2250.           message  is in response to a standard (type 0, sub-type
  2251.  
  2252.           0 or 1) message, it will be followed  by  a  Dead  Host
  2253.  
  2254.           Status  message,  which gives further information about
  2255.  
  2256.  
  2257.  
  2258.  
  2259.                              - 36 -
  2260.  
  2261.  
  2262.  
  2263.  
  2264. RFC 802                                           Andrew G. Malis
  2265.  
  2266.  
  2267.  
  2268.           the status of the dead host.  If  this  message  is  in
  2269.  
  2270.           response  to  an uncontrolled (type 0, sub-type 2 or 3)
  2271.  
  2272.           message, only sub-type 1 (The destination host  is  not
  2273.  
  2274.           up) will be used, and it will not be followed by a Dead
  2275.  
  2276.           Host Status message.
  2277.  
  2278.      Type 8: Error in Data - See 1822(3.4).
  2279.  
  2280.      Type 9: Incomplete Transmission - The  transmission  of  the
  2281.  
  2282.           named  message  was  incomplete  for  some  reason.  An
  2283.  
  2284.           incomplete transmission message is similar to  a  RFNM,
  2285.  
  2286.           but  is  a  failure  indication  rather  than a success
  2287.  
  2288.           indication.  This message is also used  by  the  short-
  2289.  
  2290.           blocking feature to indicate that the named message was
  2291.  
  2292.           rejected because it would have caused to IMP  to  block
  2293.  
  2294.           the  host  for  a long amount of time.  See section 2.4
  2295.  
  2296.           for more details concerning the short-blocking feature.
  2297.  
  2298.           The message's sub-types are:
  2299.  
  2300.           0: The destination host  did  not  accept  the  message
  2301.  
  2302.                quickly enough.
  2303.  
  2304.           1: The message was too long.
  2305.  
  2306.           2: The host took more than 15 seconds to  transmit  the
  2307.  
  2308.                message  to  the  IMP.  This time is measured from
  2309.  
  2310.                the last bit of the leader through the last bit of
  2311.  
  2312.                the message.
  2313.  
  2314.  
  2315.  
  2316.  
  2317.                              - 37 -
  2318.  
  2319.  
  2320.  
  2321.  
  2322. RFC 802                                           Andrew G. Malis
  2323.  
  2324.  
  2325.  
  2326.           3: The message was lost in the network due  to  IMP  or
  2327.  
  2328.                circuit failures.
  2329.  
  2330.           4: The IMP could not accept the entire  message  within
  2331.  
  2332.                15 seconds because of unavailable resources.  This
  2333.  
  2334.                sub-type is only used in  response  to  non-short-
  2335.  
  2336.                blocking  messages.   If  a short-blocking message
  2337.  
  2338.                timed out, it will be responded to with one of the
  2339.  
  2340.                sub-types 6-10.
  2341.  
  2342.           5: Source IMP I/O failure occurred  during  receipt  of
  2343.  
  2344.                this message.
  2345.  
  2346.           Sub-types 6-10 are all issued in response to  a  short-
  2347.  
  2348.           blocking  message that timed out (would have caused the
  2349.  
  2350.           host to become blocked for a long amount of time).  The
  2351.  
  2352.           sub-types are designed to give the host some indication
  2353.  
  2354.           of why it timed out and what other messages would  also
  2355.  
  2356.           time  out.   See  section  2.4.2  for  further  details
  2357.  
  2358.           concerning each of these sub-types.
  2359.  
  2360.           6: The message timed out because of  connection  set-up
  2361.  
  2362.                delay.   Further  messages to the same host (if on
  2363.  
  2364.                the same connection) may also be affected.
  2365.  
  2366.           7: The message timed out  because  of  end-to-end  flow
  2367.  
  2368.                control.  Further messages to the same host on the
  2369.  
  2370.                same connection will also be affected.
  2371.  
  2372.  
  2373.  
  2374.  
  2375.                              - 38 -
  2376.  
  2377.  
  2378.  
  2379.  
  2380. RFC 802                                           Andrew G. Malis
  2381.  
  2382.  
  2383.  
  2384.           8: Destination IMP buffer shortage caused  the  message
  2385.  
  2386.                to  time  out.  This affects multi-packet standard
  2387.  
  2388.                messages  to  the  specified  host,  but   shorter
  2389.  
  2390.                messages  or  messages  to hosts on other IMPs may
  2391.  
  2392.                not be affected.
  2393.  
  2394.           9: Network congestion control caused the message to  be
  2395.  
  2396.                rejected.  Messages to hosts on other IMPs may not
  2397.  
  2398.                be affected, however.
  2399.  
  2400.           10: Local resource shortage kept  the  IMP  from  being
  2401.  
  2402.                able  to  accept  the  message  within  the short-
  2403.  
  2404.                blocking timeout period.
  2405.  
  2406.           11-15: Unassigned.
  2407.  
  2408.      Type 10: Interface Reset - See 1822(3.4).
  2409.  
  2410.      Type 15: 1822L Name or Address Error - This message is  sent
  2411.  
  2412.           in  response  to  a  type  0  message  from a host that
  2413.  
  2414.           contained an erroneous Source Host or Destination  Host
  2415.  
  2416.           field.  Its sub-types are:
  2417.  
  2418.           0: The Source Host 1822L name is not authorized or  not
  2419.  
  2420.                effective.
  2421.  
  2422.           1: The Source Host 1822L address  does  not  match  the
  2423.  
  2424.                host port used to send the message.
  2425.  
  2426.           2: The Destination Host 1822L name is not authorized.
  2427.  
  2428.           3: The Destination Host 1822L name  is  authorized  but
  2429.  
  2430.  
  2431.  
  2432.  
  2433.                              - 39 -
  2434.  
  2435.  
  2436.  
  2437.  
  2438. RFC 802                                           Andrew G. Malis
  2439.  
  2440.  
  2441.  
  2442.                not  effective,  even though the named host is up.
  2443.  
  2444.                If the host were actually down, a type  7  message
  2445.  
  2446.                would be returned, not a type 15.
  2447.  
  2448.           4: The Source or  Destination  Host  field  contains  a
  2449.  
  2450.                1822L  name,  but the host being addressed is on a
  2451.  
  2452.                non-C/30 IMP (see Figure 4 in section 2.2).
  2453.  
  2454.           5-15: Unassigned.
  2455.  
  2456.      Types 11-14,16-255: Unassigned.
  2457.  
  2458.  
  2459. Bits 33-48: Source Host:
  2460.  
  2461.      For type 0 messages, this field contains the 1822L  name  or
  2462.  
  2463.      address  of  the  host  that  originated  the  message.  All
  2464.  
  2465.      replies to the message should be sent to the host  specified
  2466.  
  2467.      herein.   For  message  types  5-9,  11  and  15, this field
  2468.  
  2469.      contains the source host field used in  a  previous  type  0
  2470.  
  2471.      message sent by this host.
  2472.  
  2473.  
  2474. Bits 49-64: Destination Host:
  2475.  
  2476.      For type 0 messages, this field contains the 1822L  name  or
  2477.  
  2478.      address  that  the  message  was  sent  to.  This allows the
  2479.  
  2480.      destination host to detect  how  it  was  specified  by  the
  2481.  
  2482.      source  host.   For message types 5-9, 11 and 15, this field
  2483.  
  2484.      contains the destination host field used in a previous  type
  2485.  
  2486.      0 message sent by this host.
  2487.  
  2488.  
  2489.  
  2490.  
  2491.                              - 40 -
  2492.  
  2493.  
  2494.  
  2495.  
  2496. RFC 802                                           Andrew G. Malis
  2497.  
  2498.  
  2499.  
  2500. Bits 65-76: Message ID:
  2501.  
  2502.      For message types 0, 5, 7-9, 11 and 15, this  is  the  value
  2503.  
  2504.      assigned  by  the  source  host to identify the message (see
  2505.  
  2506.      section 3.1).  This field is also used by  message  types  2
  2507.  
  2508.      and 6.
  2509.  
  2510.  
  2511. Bits 77-80: Sub-type:
  2512.  
  2513.      This field is used as a modifier by message types 0-2,  4-7,
  2514.  
  2515.      9, 11 and 15.
  2516.  
  2517.  
  2518. Bits 81-96: Message Length:
  2519.  
  2520.      This field is contained in type 0 and type 3 messages  only,
  2521.  
  2522.      and  is  the actual length in bits of the message (exclusive
  2523.  
  2524.      of leader, leader padding, and hardware padding) as computed
  2525.  
  2526.      by the IMP.
  2527.  
  2528.  
  2529.  
  2530.  
  2531.  
  2532.  
  2533.  
  2534.  
  2535.  
  2536.  
  2537.  
  2538.  
  2539.  
  2540.  
  2541.  
  2542.  
  2543.  
  2544.  
  2545.  
  2546.  
  2547.  
  2548.  
  2549.                              - 41 -
  2550.  
  2551.  
  2552.  
  2553.  
  2554. RFC 802                                           Andrew G. Malis
  2555.  
  2556.  
  2557.  
  2558. 4  REFERENCES
  2559.  
  2560.  
  2561. [1]  Specifications for the Interconnection of a Host and an IMP,
  2562.  
  2563.      BBN Report 1822, May 1978 Revision.
  2564.  
  2565.  
  2566. [2]  E. C. Rosen et. al., ARPANET Routing Algorithm Improvements,
  2567.  
  2568.      IEN  183 (also published as BBN Report 4473, Vol. 1), August
  2569.  
  2570.      1980, pp. 55-107.
  2571.  
  2572.  
  2573. [3]  J. Postel, Assigned Numbers, RFC 790, September 1981, p. 10.
  2574.  
  2575.  
  2576.  
  2577.  
  2578.  
  2579.  
  2580.  
  2581.  
  2582.  
  2583.  
  2584.  
  2585.  
  2586.  
  2587.  
  2588.  
  2589.  
  2590.  
  2591.  
  2592.  
  2593.  
  2594.  
  2595.  
  2596.  
  2597.  
  2598.  
  2599.  
  2600.  
  2601.  
  2602.  
  2603.  
  2604.  
  2605.  
  2606.  
  2607.                              - 42 -
  2608.  
  2609.  
  2610.  
  2611.  
  2612. RFC 802                                           Andrew G. Malis
  2613.  
  2614.  
  2615.  
  2616.                               INDEX
  2617.  
  2618.  
  2619.  
  2620.  
  2621. 1822...................................................... 4
  2622. 1822 address.............................................. 6
  2623. 1822 host................................................. 5
  2624. 1822L..................................................... 4
  2625. 1822L address............................................. 7
  2626. 1822L host................................................ 5
  2627. 1822L name................................................ 6
  2628. authorized................................................ 9
  2629. blocking................................................. 16
  2630. congestion control................................... 22, 39
  2631. connection........................................... 20, 38
  2632. destination host..................................... 32, 40
  2633. effective................................................ 10
  2634. flow control......................................... 20, 38
  2635. handing type......................................... 27, 35
  2636. incomplete transmission message...................... 19, 37
  2637. leader flags......................................... 27, 35
  2638. link field............................................... 32
  2639. logical addressing........................................ 4
  2640. message ID........................................... 32, 41
  2641. message length........................................... 41
  2642. message type......................................... 28, 35
  2643. multi-homing.............................................. 4
  2644. NDM.................................................. 10, 28
  2645. NDM reply............................................ 10, 36
  2646. NOC....................................................... 9
  2647. NOP........................................... 5, 22, 30, 36
  2648. outstanding.............................................. 21
  2649. priority bit............................................. 27
  2650. regular message...................................... 28, 35
  2651. RFNM..................................................... 36
  2652. short-blocking feature................................... 15
  2653. short-blocking message............................... 19, 28
  2654. source host.......................................... 31, 40
  2655. standard message......................................... 28
  2656. sub-type............................................. 32, 41
  2657. symmetric................................................. 5
  2658. trace bit............................................ 27, 35
  2659. uncontrolled message................................. 14, 28
  2660.  
  2661.  
  2662.  
  2663.  
  2664.  
  2665.                              - 43 -
  2666.  
  2667.  
  2668.  
  2669.  
  2670.  
  2671.  
  2672.  
  2673.